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Beschreibung 

Verwaltung von mit einer erweiterbaren Auszeichnungssprache 
beschriebenen Daten 

5 

Die Erfindung betrifft ein Verfahren sowie ein System zur 
Verwaltung von mit einer erweiterbaren Auszeichnungssprache 
beschriebenen Daten. 

10 Daten werden haufig mit einer erweiterbaren Auszeichnungs- 
sprache beschrieben. Eine solche Auszeichnungssprache ist 
z • B . XML (= Extensible Markup Language) . Dieses textbasierte 
m Format wird sowohl als Austauschf ormat als auch als 
^ Speicherf ormat verwendet. Ein Nachteil des Formats ergibt 
15 sich dadurch, dass das Datenvolumen durch dieses Ablageformat 
sehr schnell sehr umfangreich werden kann. In der Datenablage 
werden oft Objekte abgelegt (z. B. Objekte aus der 
Automatisierungswelt) . Sollen diese wieder eingelesen werden, 
so kann dies recht aufwendig sein. Insbesondere wenn sich 
20 eine Applikation nur fur eine Teilmenge der Objekte bzw. nur 
einen Teil der Daten interessiert . Es muss dennoch immer die 
gesamte Datei sequenziell gelesen und bearbeitet werden, da 
mit erweiterbaren Auszeichnungssprachen Daten in Dateien 
stream-orientiert abgelegt und verarbeitet werden. 

Der Erfindung liegt die Aufgabe zugrunde, die Verwaltung von 
mit einer erweiterbaren Auszeichnungssprache beschriebenen 
Daten zu vereinf achen. 

30 Diese Aufgabe wird durch ein Verfahren zur Verwaltung von mit 
einer erweiterbaren Auszeichnungssprache beschriebenen Daten 
gelost, wobei die Daten in Form von Objekten strukturiert 
werden, wobei Bestandteile der Objekte in ersten Dateien 
speicherbar sind, wobei die Bestandteile jeweils eine 

35 logische Einheit eines Objekts abbilden und wobei eine zweite 
Datei mit ersten Mitteln zur Ref erenzierung der Bestandteile 




200216722 




2 

als iibergeordnete, obj ektbasierte logische Ebene zur 
Speicherung der Objekte vorgesehen ist. 

Diese Aufgabe wird durch ein System zur Verwaltung von mat 
einer erweiterbaren Auszeichnungssprache beschriebenen Daten 
gelost, wobei Objekte zur Strukturierung der Daten vorgesehen 
sind, wobei Bestandteile der Objekte in ersten Dateien 
speicherbar sind, wobei die Bestandteile jeweils eine 
logische Einheit eines Objekts abbilden und wobei eine zweite 
Datei mit ersten Mitteln zur Ref erenzierung der Bestandteile 
als tibergeordnete, obj ektbasierte logische Ebene zur 
Speicherung der Objekte vorgesehen ist. 

Objektgeflechte werden oft in einer grofien Datei abgelegt 
oder aber auf eine Vielzahl kleiner Dateien aufgeteilt. 
Zusammenhange zwischen Objekten sind entweder durch die 
Ablagestruktur vorgegeben oder aber durch Links, die Verweise 
zwischen den Dateien und darin befindliche Objekte 
reprasentieren, abgebildet. Die Erfindung schlagt ein 
Verfahren sowie ein System vor, mit dem man die Ablage von 
Objekten und Objektgef lechten auf mehrere Dateien aufteilen 
kann. Der Zugriff auf das Obj ektgef lecht wird dabei 
optimiert. Die Anzahl zu lesender Dateien - und damit die 
Datenmenge, die gelesen werden muss - wird reduziert. 
Grundlage hierfur ist, dass aber der Ebene mit in einer 
reinen Auszeichnungssprache beschriebenen Daten eine weitere, 
logische Ebene fur Objekte definiert wird. D. h. ein 
Verfahren bzw. System zur Abbildung von Objekten mit ihren 
Daten in der Auszeichnungssprache. Applikationen, die die 
Daten lesen, mttssen nicht das gesamte Objektgef lecht und 
dessen Daten lesen, sondern konnen die logische Objektebene 
nutzen urn nur bis bis zu der Granularitat lesen, die sie ftir 
ihre Arbeiten auf dem Obj ektgef lecht benotigen. Tools, die 
bestimmte Teile des Obj ektgef lechts nicht benotigen, konnen 
so die entsprechenden Stellen sehr leicht Uberlesen, da die 
Daten bzw. die Inf ormationen in separaten Auslagerungsdateien 
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abgelegt werden. Diese Teile mussen vom Parser der 
Auszeichnungssprache nicht eingelesen und bearbeitet werden. 
Es konnen Teile (im Folgenden auch Features genannt) eines 
Objekts in erste Dateien ausgelagert werden. In der 
5 jeweiligen ersten Datei werden ein oder mehrere ausgelagerte 
Objektteile abgelegt. In der Ursprungsdatei verbleibt in 
diesem Fall das Objekt. Nur ein oder mehrere Features des 
Objekts werden ausgelagert. Dies ermoglicht Navigierbarkeit 
auf das Objekt innerhalb der Ursprungsdatei bis hin zum 
10 ausgelagerten Objektteil (Feature) . Zudem bleiben die 
Objektteile verschiebbar, ohne dass Referenzen hierauf 
geandert werden mussen. 

Gemafi einer vorteilhaf ten Ausgestaltung der Erfindung sind 
15 die ausgelagerten Bestandteile selbst Objekte. In der zweiten 
Datei, auch Ursprungsdatei genannt, verbleibt jeweils nur ein 
Objektrumpf in Form einer Auslagerungsref erenz . Dies stellt 
sicher, dass Referenzen auf das ausgelagerte Objekt sich 
nicht von anderen Obj ektref erenzen, die Objekte oder 
2 0 Objektteile in der Ursprungsdatei ref erenzieren, 

unterscheiden. Es muss am Ursprung der Ref erenz nicht bekannt 
sein, dass es sich bei dem Zielobjekt um ein ausgelagertes 
Objekt handelt. In der jeweiligen ersten Datei, auch 
Auslagerungsdatei genannt, wird das ausgelagerte Objekt als 

©Ganzes abgelegt. Ein Objekt kann somit verschoben werden, 
ohne dass Referenzen auf das Objekt zu andern sind. Des 
Weiteren wird Navigierbarkeit auf das Objekt innerhalb der 
Ursprungsdatei bzw. von Aufien ermoglicht. 

30 Vorteilhafterweise werden die Features genannten Bestandteile 
der Objekte in obj ektspezif ischen generischen Containern 
gespeichert, wobei die Container zur Ref erenzierung des 
jeweiligen Objekts dienen. In der Auslagerungsdatei werden 
die Features also in einem Container, im Folgenden auch 

35 Stellvertreterobjekt oder ObjektSurrogate genannt, abgelegt. 
Dieses Stellvertreterobjekt reprasentiert in generischer 
Weise eine Httlle ftir die Daten des Objekts und bildet den 
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Kontext fur die Ablage der Features. Der Kontext ist dabei 
die Identif ikation des Objekts, wie es in der Ursprungsdatei 
identifiziert wird. Es gibt somit ein Stellvertreterobj ekt in 
der Auslagerungsdatei, das beschreibt zu welchem Objekt in 
5 der Ursprungsdatei die Daten gehoren. Das Stellvertreter- 
obj ekt ist ein Objekttyp, der ein generisches Objekt 
reprasentiert und beliebige Features aufnehmen kann. In der 
Auslagerungsdatei stehen die Daten des Objekts nicht alleine, 
sondern haben durch das Stellvertreterobj ekt einen Bezug zum 
10 eigentlichen Objekt in der Ursprungsdatei und stellen somit 
eine Riickwartsref erenz zur Verftigung. 

•Nachfolgend wird die Erfindung anhand der in den Figuren 
dargestellten Ausf tihrungsbeispiele naher beschrieben und 
15 erlautert . 

Es zeigen: 

FIG 1 eine schematische Darstellung der Auslagerung eines 

2 0 Objekts in eine Auslagerungsdatei und 

FIG 2 eine schematische Darstellung der Auslagerung eines 

Teils eines Objekts in eine Auslagerungsdatei. 

©In den Ausf iihrungsbeispielen wird XML als Beispiel fur eine 
erweiterbare Auszeichnungssprache verwendet. Daten in XML- 
Dateien werden sequenziell gelesen und nicht benotigte Teile 
der Datei Uberlesen. Dabei ist die XML-Syntax sehr hilfreich. 
Sie sieht vor, dass Daten immer mit einem Start- und Ende-Tag 
30 gleichen Namens versehen werden (z. B. <DisplayName>) bzw» 
das Tag sofort wieder geschlossen wird (z. B. <Text .../>) 

Beispiel : 



35 



<DisplayName> 

<Text Value="DP-Master n /> 
</DisplayName> 
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Somit ist es fttr das einlesende Tool („Parser* genannt) 
moglich, Daten beginnend bei einem bestimmten Start-Tag bis 
zum zugehorigen Ende-Tag zu iiberlesen. Der Inhalt des Files 
5 zwischen den Tags muss jedoch dennoch gelesen werden, auch 
wenn die Daten nicht verarbeitet werden. Eine Methode zum 
Aufteilen von Datenbestanden auf mehrere File bietet das vom 
W3C Konsortium vorgeschlagene XML-Inclusions (XInclude) 
Konstrukt. Dies gehort zu den Basisdef initionen von XML, die 
10 vom W3C (= World Wide Web Consortium) momentan erarbeitet 

werden. XInclude funktioniert als einfacher Mechanismus, urn 

•XML oder Textdateien in ein XML Dokument zu inkludieren. Dies 
geschieht analog dem aus C/C++ bekannten ttinclude als 
textuelle Ersetzung des Xinclude-Tags durch das andere 
15 Dokument. Es konnen dabei entweder das gesamte Dokument oder 
nur Teile daraus (spezif iziert durch einen XPointer, siehe 
XML-Spezifikation) eingebettet werden. Dies lost jedoch nicht 
das Problem des Oberlesens von nicht benotigten Objektteilen, 
da XML-Parser automatisch die ref erenzierten Dateien beim 
20 Lesen mit einfligen. Die zu hantierende Datenmenge bleibt 
dabei gleich. Beim Uberlesen von nicht interessierenden 
Teilen der Datei gilt dasselbe wie oben beschrieben. Das 
Problem hierbei ist, dass XML an sich nur Daten reprasentiert 
und kein Obj ektmodell kennt. Somit konnen logisch in Objekten 

Ozusammenhangende Daten auf XML Ebene nicht erkannt werden. 
Eine weitere, heute gebrauchliche Moglichkeit ist die 
Aufteilung grofier Datenfiles auf eine Vielzahl kleiner 
Dateien. Hierbei wird typischerweise so "vorgegangen, dass die 
Grenze zwischen Dateien auch immer die logische Objektgrenze 
30 bildet. Damit werden Objekte der Anwendungs ebene in einer 

Datei abgelegt. Der Bezug zwischen Objekten wird durch einen 
Link auf die Datei abgebildet. Somit fehlt in der 
Ursprungsdatei die Information tiber das Objekt in der 
Zieldatei - es exlstiert typischerweise nur die Information, 
35 dass dort ein oder mehrere Objekte abgelegt sind. 
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Urn die Hantierung von groflen XML-Da tenmengen, die Objekte mit 
ihren Daten beinhalten, zu optimieren, kann die Ablage dieser 
Daten auf mehrere Dateien aufgeteilt werden. Hierfur wird ein 
XML-Schema zur Ablage von Objekten und ihrer Bestandteile 
definiert. Oberhalb der Ebene des reinen XML wird somit eine 
weitere, objektbasierte logische Ebene eingeftihrt. Auf dieser 
Ebene ist es moglich, Objekte bzw. Teile von Objekten auf 
mehrere Dateien zu verteilen. Dabei mtissen nicht mehr alle 
Objekte in einer Gesamtdatei abgelegt werden. Stattdessen ist 
es moglich, Objekte so abzulegen, dass die Kerninf ormation, 
die notwendig ist, um das Objekt und dessen Typ zu 
identif izieren, in einem Ursprungsf ile vorhanden ist. Die 
eigentliche (meist umf angreiche) Nut zinf ormation des Objekts 
wird jedoch in ein Auslagerungsf ile ausgelagert. In diesem 
konnen Daten von einem oder mehreren Objekten abgelegt sein. 
Hierbei macht man sich zu Nutze, dass Objekte meist aus 
verschiedenen „Arten von Daten* bestehen. So kann man diese 
unterscheiden in Daten, 

- die das Objekt an sich beschreiben (Obj ektidentif ikation, 
Name, etc. ) , 

- die von allgemeinem Interesse sind und damit ftir 
verschiedene Applikationen bzw. Teile von Applikationen 
von Interesse sind und 

- die sehr spezifisch sind und nur fur eine bestimmte 
Applikation bzw. eine Teil-Applikation von Interesse sind. 

Dies kann man ausnutzen, um ein Objekt in logische 
Bestandteile aufzuteilen und diese ggf . entsprechend den 
Hauptverwendungen optimiert in verschiedenen Dateien 
abzulegen. Tools, die bestimmte Teile des Objektgef lechts 
nicht: benotigen, konnen so die entsprechenden Stellen sehr 
leicht tiberlesen, da die Inf ormationen in separate 
Auslagerungsf iles abgelegt werden. Diese Teile mtissen vom 
XML-Parser nicht eingelesen und bearbeitet werden. Die Daten 
eines Objekts werden dementsprechend in verschiedene 
Bestandteile aufgeteilt, die logische Einheiten bilden und 
bestimmte Aspekte eines Objekts reprasentieren. Grundlage der 
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Gruppierung ist die logische Zusammengehorigkeit der 
Bestandteile des Objekts zu einer bestimmten „Sicht* (z. B. 
HMI , Hardware, Software) auf das Objekt. Diese Bestandteile 
werden im Folgenden auch als Features bezeichnet. Sie 
gruppieren die Parameter, Referenzen, etc. des Objekts. Uber 
der syntaktischen Ebene von reinem XML wird also ein 
logisches Objektmodell und ein Mechanismus zur Aufteilung von 
Objektdaten definiert, der es gestattet Obj ektgef lechte in 
hierarchisch strukturierte Dateien abzulegen und dabei die 
Daten von Objekten auf mehrere Dateien zu verteilen, die den 
unterschiedlichen Anf orderungen fur den Datenzugriff genugen, 
d. h. die wichtigsten UseCases fur die Nutzung der Daten 
unterstiitzen. 

Dem liegen folgenden Grundideen zugrunde: 

- Die in XML abzulegenden Daten werden als Objekte 
modelliert und konnen Uber XML-Schema beschrieben werden. 
Hierdurch ist es moglich eine Semantik fur die Auslagerung 
von Objekten zu definieren. Dabei ist es sinnvoll, dass 
alle Objekttypen im XML-Schema von einem Basis-Ob jekttyp 
abgeleitet werden. Dies ist jedoch nicht zwingend 
erforderlich. 

- Es wird ein Mechanismus festgelegt, wie Objekte bzw. 
Obj ektgef lechte auf mehrere Dateien aufgeteilt werden 
konnen . 

- Die Auftrennung zwischen Dateien erfolgt an solchen 
Stellen, an denen im Objektmodell eine PartOf-Beziehung 
herrscht. Die Annahme hierbei ist, dass, wenn ein Objekt 
aus weiteren Subobjekten besteht, diese Subobjekte 
typischerweise Kandidaten fUr die Auslagerung darstellen. 
Applikationen bzw. Teile von Applikationen greifen haufig 
auf unterschiedlicher Granularit&tsstuf e auf Objekte zu. 
So interessiert in der einen Applikation beispielsweise 
nur um welches Objekt es sich handelt. Erst zur 
Bearbeitung des Objekts (z. B. in einem Editor) sind die 
Subobjekte dieses Objekts von Interesse. Erst dann wird 
auf diese Teildaten zugegriffen. 
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- In der Ursprungsdatei verbleibt ein Objektrumpf in Form 
einer Auslagerungsref erenz . Dies stellt sicher, dass 
Referenzen auf das ausgelagerte Objekt sich nicht von 
anderen Objektref erenzen unterscheiden. Es muss am 
Ursprung der Referenz nicht bekannt sein, dass es sich bei 
dem Zielobjekt urn ein ausgelagertes Objekt handelt. In der 
Auslagerungsdatei wird das ausgelagerte Objekt als Ganzes 
abgelegt. Das hat folgende Vorteile: 

- Referenzen auf ausgelagerte Objekte mtissen sich nicht 
unterscheiden von Referenzen auf nicht ausgelagerte 
Objekte. 

- Objekt kann verschoben werden, ohne dass Referenzen auf 
das Objekt zu andern sind. 

- Navigierbarkeit auf das Objekt innerhalb der 
Ursprungsdatei bzw. von AuJJen ist gegeben 

- Es konnen auch Teile eines Objekts (Features) in eine 
Datei ausgelagert werden. In der Ursprungsdatei verbleibt 
in diesem Fall das Objekt. Nur ein oder mehrere Features 
des Objekts werden ausgelagert. In der Auslagerungsdatei 
werden die Features in einem ObjektSurrogate abgelegt. 
Dieses Stellvertreterobj ekt reprasentiert in generischer 
Weise eine Htille fttr die Daten des Objekts und bildet den 
Kontext fur die Ablage der Features. Der Kontext ist dabei 
die Identif ikation des Objekts, wie es in der 
Ursprungsdatei identif iziert wird. Das hat folgende 
Vorteile : 

- Es gibt einen Stellvertreter in der Auslagerungsdatei , 
der beschreibt zu welchem Objekt die Daten gehoren. 

- Der Stellvertreter ist Objekttyp, der ein generisches 
Objekt reprasentiert und beliebige Features aufnehmen 
kann. 

- Navigierbarkeit auf das Objekt innerhalb der 
Ursprungsdatei bis hin zum ausgelagerten Objektteil 

(Feature) ist gegeben. 

- Verschiebbarkeit des Objektteils ohne Referenzen hierauf 
andern zu mtissen (Objekt enthalt Rumpf inf ormationen liber 
ausgelagertes Objektteil) . 
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- In der Auslagerungsdatei stehen die Daten des Objekts 
nicht alleine, sondern haben durch das Stellvertreter- 
Objekt einen Bezug zum eigentlichen Objekt in der 
Ursprungsdatei (Eine Art Riickwartsref erenz) 

Die Referenzen auf ausgelagerte Objekte beinhalten 
verschiedene Daten (als XML-Attribute oder ggf . auch als XML- 
Elemente) : 

- Identifikationsdaten des Objekts (z. B. Objekt-ID, Objekt- 
Name, etc.) 

- Zieldatei in der das Objekt zu finden ist (z. B. Name und 
Pfad der Datei) 

- Identifikationsdaten des Objekts in der Zieldatei (z. B. 
Objekt-ID, Objekt -Name) 

Durch diesen Aufbau der Referenz kann die Adressierung des 
Objekts in der Auslagerungsdatei unabhangig von der 
Identif ikation des Objekts geandert werden. Regeln, an 
welchen Stellen in XML-Dateien abgelegte Objekte bzw. 
Objektgef lechte aufzuteilen sind, sind spezifisch fur den 
Anwendungsf all zu definieren und in ein entsprechendes XML- 
Schema umzusetzen. 

Ein Beispiel fur die Anwendung der Erfindung ist der Export 
von Daten aus einer Applikation, urn diese in anderen 
Applikationen weiterverarbeiten zu konnen. In einer 
Applikation werden Objekte in Baumen strukturiert (mit 
Querverweisen durch Referenzen auf beliebige Objekte) . Eine 
Auslagerung von Objekten in andere Dateien erfolgt nur an 
Teilbaumgrenzen. Alle Objekte und Features auf oberster 
logischer Ebene in einer ausgelagerten Datei gehoren deshalb 
zum gleichen Obj ekt/Feature in der ursprtinglichen Datei. 
Dadurch entsteht bei der Aufteilung des XML-Exports in 
mehrere Dateien automatisch eine baumartige Hierarchie von 
Dateien. Es gibt mehrere MSglichkeiten, wie man ein (logisch 
zusammengehorendes) Obj ektgef lecht auf mehrere Dateien 
verteilen kann: 
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- Aufteilung objektgranular : SubObjekte, die zu einem Objekt 
gehoren werden nicht in der ursprunglichen Datei 
eingebettet, sondern in eine externe Datei geschrieben. 

- Aufteilung an Feature-Grenzen: Einzelne Features werden in 
getrennten Dateien abgelegt. Dies ist z. B. dann 
vorteilhaft, wenn eine Anwendung ihre Daten in eigene 
Features ablegt, die im Wesentlichen nur fur diese 
Applikation relevant sind, nicht aber fur andere. Falls 
diese in einer eigenen Datei liegen, braucht die Anwendung 
nur diese Datei zu lesen. 

Eine Datei, die ausgelagerte Objekte enthalt, unterscheidet 
sich in ihrem Aufbau nicht von anderen Dateien, in denen 
Objekte abgelegt werden. Jede XML-Datei beginnt mit einem 
Standard-Header zur Identif ikation, dass diese XML-Datei zu 
einer Menge von Export-Dateien gehort, die das abgelegte 
Objektgeflecht beinhalten. 

Zusatzliche Vorteile bietet es, die hierarchischen 
Abhangigkeiten zwischen den Dateien in einem Export eines 
Objektgeflechts explizit mit anzugeben. Dies ist jedoch nicht 
notwendig und bietet nur zusatzlichen Nutzen dadurch, dass 
eine beliebige Datei des Exports als Einstieg fur die 
Bearbeitung verwendet werden kann. Es bietet eine einfache 
Navigation auf Dateiebene, urn von jeder beliebigen Datei aus 
zum Wurzelelement bzw. zum direkten (logischen) Parent 
(= Elternelement) der Datei zu gelangen. Hierzu wird fur den 
Aufbau einer (Export-) Datendatei (z. B. <Document>) ein 
Standard-Header definiert. In diesem Header konnen zwei 
optionale Attribute Parent und Root vorgesehen werden. Mit 
Parent gibt man die nachsthohere Datei der Hierarchie an, mit 
Root direkt die Wurzel, also das oberste Element der 
Hierarchie. Wenn man diese beiden Attribute verwendet, ist es 
moglich, von einer beliebigen Datei innerhalb eines Exports 
zur Wurzel des Exports bzw. zu dem File zu gelangen, von dem 
die Objektdaten der aktuellen Datei referenziert werden. 
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Der Aufbau des Headers und der gesamten XML Datei kann dabei 
tiber XML-Schema festgelegt werden. Ein Beispiel ftlr eine 
Instanz einer Exportdatei kann wie folgt aussehen (siehe auch 
FIG 1 ) . 

5 

Beispiel-Datei Racks. xml 20: 
<Document 

xmlns :base="http: //www. siemens.com/Industry/2001/Automation/Base" 

Parent="HWKonf igExport .xml" Root="HWKonf igExport . xml"> 
<FileInfo Version="l . 2"> 

</FileInfo> 
</Document> 

Die Datei Racks. xml 20 ist Teil eines XML-Exports, dessen 
Wurzel die Datei HWKonf igExport .xml 10 bildet. Diese Datei 10 
ist gleichzeitig der Vaterknoten von Racks. xml 20 im Baum des 
XML-Exports. Die Parent-Beziehung und die Root-Beziehung sind 
in FIG 1 durch die mit den Bezugszeichen 2 bzw. 3 
bezeichneten Pfeile dargestellt. 



Q 



Lagert man ein Objekt mit seinen Daten in eine eigene Datei 
aus, so benotigt man an der Stelle, wo "normalerweise" das 
Objekt eingebettet ware, eine spezielle Referenz 13 
(ReferencePartOfT) . Diese Referenz 13 gibt an, dass es sich 
um eine Auslagerung 23 handelt. Die Referenz 13 spezifiziert 
dabei welches Objekt ausgelagert wurde und in welcher Datei 
es zu finden ist. Die Beziehung zwischen Referenz 13 auf der 
30 einen Seite und Auslagerung 23 auf der anderen Seite ist in 
FIG 1 durch einen Pfeil mit dem Bezugszeichen 1 dargestellt. 
Ein Beispiel fur eine Schema-Definition einer Auslagerungs- 
referenz konnte wie folgt aussehen: 



35 



<xsd: complexType name= "Reference Part Of T"> 
<xsd : complexContent> 
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<xsd: attribute name^'Name" type="xsd: string" us e=" optional "/> 

<xsd: attribute name=" Target" type="xsd: string" use="required"/> 

<xsd: attribute name="TargetID" type="IdT" use="required"/> 
<xsd: attribute name=" TargetName" type="xsd: string" use=" required" /> 
5 </xsd: complexContent> 

</xsd: complexType> 

Die Attribute TargetID 11 und TargetName 12 enthalten die ID 
21 und den Namen 22 des ausgelagerten Objekts, auf das die 
10 Referenz 13 verweist. Die ID 21 wird fur die Bildung von 

absoluten Referenzen von einer anderen Stelle auf das Objekt 

•benotigt. Deiu Objekt kann auch ein Name 22 gegeben werden, 
den man ebenfalls zur Ref erenzierung verwenden kann. Auch 
wenn ein Objekt ausgelagert wird, sind durch diese beiden 
15 Attribute TargetName 12 und TargetID 11 der Name 22 bzw. die 
ID 21 noch im Hauptdokument vorhanden. Dies hat den Vorteil, 
das alle Ref erenzierungen auf dieses Objekt in dem File 
navigiert werden konnen. D. h. wenn das Ursprungsf ile des 
Objekts von einer Applikation eingelesen/verarbeitet wird, so 

2 0 konnen Referenzen auf das Objekt aufgelost und das Objekt bei 

Bedarf aus der ausgelagerten Datei gelesen werden. 

Der Einsatz von Auslagerungsref erenzen ist sehr einfach, es 
wird nur das eingebettete Objekt (im Beispiel das "Rack") 

©durch eine Auslagerungsref erenz (im Beispiel "RackLink") 
ersetzt. Das Element wird im produktspezif ischen Schema als 
Element vom Typ product : Ref erencePartOf T definiert. 

Beispiel fur den Einsatz der Auslagerungsref erenz : 

30 <base:Station ID= ,f 1234" Name= ll S7300 II > 
<base: StructuralFeature> 

<base: RackLink TargetName="UR" 
TargetID="4711 M 

Target=" . . /Drehen/Racks . xml#4711 f 7> 

3 5 </base : StructuralFeature> 

</base:Station> 
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Die Definition der Auslagerung des Objekts (Rack) kann im 
XML-Schema ftlr das Ursprungsobj ekt in diesem Fall wie folgt 
definiert werden: 

<xsd: element name="RackLink" type="Ref erencePartOfT" /> 

Die Auslagerung von einzelnen Features eines Objekts ftihrt 
dazu, dass in der Auslagerungsdatei eigentlich kein 
vollstandiges Ob j ekt mehr vorhanden ist, sondern nur ein Teil 
des Objekts. An der Stelle im Ursprungsdokument, an der sonst 
das Feature abgelegt wtirde, steht nur noch ein Link auf das 
ausgelagerte Feature. Beispiel: 

<SubSystem ID="100" Name="DP-Master"> 
<DisplayNameFeature> 

<DisplayNameFeature> 
<ProfibusFeatureLink 

Target="Feature.xmllioo/feature (Prof ibusFeature) "/> 

</SubSystem> 

In der Auslagerungsdatei steht das eigentliche Feature. Damit 
dieses Feature wieder einem Ob j ekt zugeordnet werden kann, 
wird dieses Feature in einer Standard-Objekthulle (auch 
ObjectSurrogate genannt) abgelegt. Beispiel ftir das in obigem 
Beispiel ausgelagerte Prof ibusFeature : 

<ObjectSurrogate ID= n 100" Name="DP-Master"> 
<ProfibusFeature> 

<GROUP_I DENT_SUM_ALL__S LAVES Value= " 2 55 "/ > 
<GROUP_SYNC_PR0P Value="255 "/> 
<GROUP_FREEZEJPROP Value= M 255 "/> 
<LAST_USED_PROFIBUS_ADDR Value=" 12 "/> 
<Address Value="12 H /> 
</ProfibusFeature> 
</Ob jectSurrogate> 
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Diese Objekthulle (Obj ectSurrogate) ist ein generischer 
Container zur Aufnahme von ausgelagerten Features. Er ist 
nicht spezifisch fur den Applikations-Obj ekttyp, dessen Daten 
er enthalt. Die Objekthttlle dient zur Etablierung des 
entsprechenden Kontexts fur den Objektteil und beinhaltet die 
Identifikation des Objekts (ID und Name). Wie man in den 
Instanzen sieht, sind ID und Name in der Haupt-Datei und in 
der Auslagerungsdatei jeweils gleich. FIG 2 verdeutlicht 
diesen Zusammenhang. Mit dem Bezugszeichen 50 wird die 
ursprungliche Situation gekennzeichnet, wenn alles in einer 
Datei abgelegt wird: Das Objekt Subsystem 51 hat die beiden 
Features DisplayNameFeature 52 und Prof ibusFeature 53. Mit 
dem Bezugszeichen 60 wird die Konstellation bezeichnet, bei 
der das Prof ibusFeature 63 in eine eigene Datei 65 
ausgelagert ist. Die Definitionen der benotigten Typen im 
XML-Schema konnte beispielhaft folgendermafien aussehen: 

<xsd:complexType name="Obj ectSurrogateT "> 
<xsd: anno tat ion> 

<xsd:documentation>object that contains features in partial 
exports</xsd: documentation 
</xsd: annotation> 
<xsd: complexContent> 

<xsd: restriction base="Obj ectT"> 
<xsd : sequence> 

<xsd: element name="App_Id" type="ApplicationSpecif icIdT" minOccurs="0" 
maxOccurs=="unbounded ff /> 

<xsd: element ref«" Feature" maxOc cur s=" unbounded" /> 
30 </xsd:sequence> 
</xsd: restriction 
</xsd: complexContent> 
</xsd: complexType> 

<xsd: element name=" Feature" type="FeatureT"/> 
35 <xsd: element name="Prof ibusFeature" type="Prof ibusFeatureT" 
substitutionGroup="Feature"> 

<xsd: attribute name="Name" type="xsd:QName" use="optional"/> 
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<xsd: attribute name="Target" type="xsd: string" use=" required "/> 
<xsd: attribute name="Type" type="Ref erenceTypeEnumT" us e=" optional" 

fixed="PartOf "/> 

</xsd: complexType> 

5 

Der Typ von Prof ibusFeature ist vom Grundtyp FeatureT 
abgeleitet. Da bei der Elementdeklaration die 
SubstitutionGroup Feature angegeben wurde, kann das Element 
in das Obj ectSurrogate an Stelle von Feature eingehangt 
10 werden, 

•Die Hantierung von Auslagerungen kann bei einer konkreten 
Implementierung durch eine Supportbibliothek unterstutzt 
werden. Diese kann sowohl beim Lesen der XML-Daten, als auch 
15 beim Schreiben automat isch die Aufteilung der XML-Daten auf 
Files hantieren und den Mechanismus fur den Anwender 
verbergen. Aus seiner Sicht operiert er ausschliefilich auf 
dem Objektmodell. Verwaltung von Dateien und Referenzen 
erfolgt durch die Supportbibliothek. Voraussetzung hierfur 
20 ist, dass entsprechende Schemas fur die Applikationsdaten 
existieren und diese von der Supportbibliothek benutzt 
werden . 

Zusammenfassend betrifft die Erfindung somit ein System sowie 

©ein Verfahren zur vereinf achten Verwaltung von mit einer 
erweiterbaren Auszeichnungssprache beschriebenen Daten. Dabei 
werden die Daten in Form von Objekten strukturiert, wobei 
Bestandteile der Objekte in ersten Dateien speicherbar sind, 
wobei die Bestandteile jeweils eine logische Einheit eines 
30 Objekts abbilden, und wobei eine zweite Datei mit ersten 
Mitteln zur Ref erenzierung der Bestandteile als 
iibergeordnete, obj ektbasierte logische Ebene zur Speicherung 
der Objekte vorgesehen ist. 
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Patentansprtiche 

1. Verfahren zur Verwaltung von mit einer erweiterbaren 
Auszeichnungssprache beschriebenen Daten, wobei die Daten in 
Form von Objekten strukturiert werden, wobei Bestandteile der 
Objekte in ersten Dateien speicherbar sind, wobei die 
Bestandteile jeweils eine logische Einheit eines Objekts 
abbilden und wobei eine zweite Datei mit ersten Mitteln zur 
Referenzierung der Bestandteile als ubergeordnete, 
objektbasierte logische Ebene zur Speicherung der Objekte 
vorgesehen ist. 



2. Verfahren nach Anspruch 1, 

dadurch gekennzeichnet, 
dass die Bestandteile selbst Objekte sind. 

3. Verfahren nach Anspruch 1, 

dadurch gekennzeichnet, 
dass die Bestandteile in objektspezif ischen generischen 
Containern gespeichert werden, wobei die Container zur 
Referenzierung des jeweiligen Objekts dienen. 

4. System zur Verwaltung von mit einer erweiterbaren 
Auszeichnungssprache beschriebenen Daten, wobei Objekte zur 
Strukturierung der Daten vorgesehen sind, wobei Bestandteile 
der Objekte in ersten Dateien speicherbar sind, wobei die 
Bestandteile jeweils eine logische Einheit eines Objekts 
abbilden und wobei eine zweite Datei mit ersten Mitteln zur 
Referenzierung der Bestandteile als ubergeordnete, 
objektbasierte logische Ebene zur Speicherung der Objekte 
vorgesehen ist. 



5. System nach Anspruch 4, 

dadurch gekennzeichnet, 
dass die Bestandteile selbst Objekte sind. 
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6. System nach Anspruch 4, 

dadurch gekennzeichnet, 
dass objektspezif ische generische Container zur Speicherung 
der Bestandteile der Objekte vorgesehen sind, wobei die 
Container zur Ref erenzierung des jeweiligen Objekts dienen. 
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Zusammenf as sung 

Verwaltung von mit einer erweiterbaren Auszeichnungssprache 
beschriebenen Daten 

Die Erfindung betrifft ein System sowie ein Verfahren zur 
vereinf achten Verwaltung von mit einer erweiterbaren 
Auszeichnungssprache beschriebenen Daten. Dabei werden die 
Daten in Form von Objekten strukturiert, wobei Bestandteile 
der Objekte in ersten Dateien speicherbar sind, wobei die 
Bestandteile jeweils eine logische Einheit eines Objekts 
abbilden und wobei eine zweite Datei mit ersten Mitteln zur 
Ref erenzierung der Bestandteile als ubergeordnete, 
obj .ektbasierte logische Ebene zur Speicherung der Objekte 
vorgesehen ist . 
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